개요

1.0 버전으로 서비스를 배포하고 있다고 생각해보자.
이때 버전을 1.1 버전으로, 혹은 이전 버전으로 롤백을 하고 싶다면 어떻게 해야 하는가?
서비스를 배포하는 방법에는 여러 가지가 있다.
가장 단순하게는 현재 운영 중인 서비스를 내리고, 이후에 새로운 버전을 새롭게 띄우는 방법이 있다.
그러나 이렇게 하면 서비스 도중 다운타임이 발생하는 이슈가 있다.
이를 해결하기 위해 다양한 전략이 존재한다.

이 전략들은 이전 버전과, 새로운 버전을 배포를 어떻게 할 것인가에 대한 해결책들이다.
편의를 위해 이전 버전을 블루, 새로운 버전을 그린이라고 표현하겠다.

Recreating

이건 위에서 말한 단순한 방법으로 블루 버전을 완전히 내린 이후에 그린 버전을 배포하는 방법이다.

• 장점
  • 한정된 자원이 있는 환경에서 추가적인 자원의 소모 없이 배포할 수 있다.
  • 단순하다.
• 단점
  • 서비스 다운타임이 발생한다.

위 단점으로 인해, 실제 서비스를 하는 기업이라면 이런 방법은 지양하는 것이 좋다.
하지만 게임 서비스의 경우에는 이러한 전략이 현재도 사용된다.
모든 사람들이 동시에 접속하면서 같은 버전임이 보장되어야만 원활한 서비스가 가능하기 때문이다.
이 경우에는 아예 점검 시간을 따로 두고 이러한 전략을 취한다.
대신 새벽 시간을 써가면서 엔지니어들의 수면 시간을 갈아 넣어야만 한다..

Rolling

여기에서부터는 무중단(Zero Downtime) 배포 방법이다.
롤링 전략.

현재 존재하는 블루 버전의 서비스를 한두 개씩 내린다.
그리고 확보된 자원 위에 그린 버전의 서비스를 올린다.
이러한 과정을 반복한다.
즉, 업데이트해야 할 애플리케이션 프로세스들을 순차적으로 돌아가면서(rolling) 업데이트하는 방식을 말한다.

• 장점
  • 무중단이 가능하다.
  • 한정된 자원이 있는 환경에서 추가적인 자원의 소모 없이 배포할 수 있다.
  • 롤백도 가능하다.
• 단점
  • 배포 도중에는 조금씩이라도 배포된 프로세스 수가 줄어들어 트래픽 처리 용량이 줄어들게 되므로 이에 대한 유의가 필요하다.
  • 사용자에게 의도적이지 않게 버전이 업데이트되는 서비스 경험을 선사할 수도 있다..

이것도 한정된 자원을 가지고 있을 때 유효한 방법이다.

쿠버네티스의 Deployment를 활용하면 이 전략을 매우 쉽게 사용할 수 있다.
기본 업데이트 방식이 rollingUpdate이기 때문이다.
E-디플로이먼트 조작#디플로이먼트 업데이트 참고

Blue-Green

블루 그린 전략.
이 배포 이름 때문에 내가 버전에 블루와 그린이라는 이름을 붙였다.

그린 버전을 새로 띄운다.
이후 그린 버전이 정상적으로 동작하는 것이 확인된다면 트래픽을 그린 버전으로 라우팅한다.
그리고 블루 버전을 없앤다.

• 장점
  • 무중단이 가능하다.
  • 모든 트래픽은 같은 버전의 서비스를 사용하는 것이 보장된다.
• 단점
  • 블루 버전이 서비스되고 있을 때 완전히 새롭게 그린 버전을 띄워야 하기에 현재 가용한 자원이 평소 서비스하는 양의 두 배 이상이어야만 한다.

새로운 버전이 완전히 만들어진 이후에 버전을 교체하는 거라, 사실 가장 좋은 방법이 아닐까?
그러나 이것도 넉넉한 자원을 가지고 있을 때나 가능한 일이다.
실제 운영에 있어서 간혹 가다 있을 업데이트를 위해, 따블의 리소스를 항상 마련해두는 것은 얼마나 비효율적인 일인가.
다만 프로비저닝이 용이한 클라우드 서비스를 활용한다면 충분히 유효한 전략이 될 수 있다.

Canary

카나리 전략.
탄광에서 유독 가스에 민감한 카나리 새를 활용해 환경을 체크했다는 것에 이름이 유래했다.

블루 버전이 있는 상태에서 그린 버전을 몇 개 띄운다.
이때 새로 생긴 그린 버전에도 트래픽이 라우팅되도록 한다.
즉, 사용자들의 트래픽은 몇 개는 블루로, 몇 개는 그린으로 간다는 것이다.
그리고 운영자의 입맛대로 그린을 더 늘리거나, 블루를 줄이거나 하면서 업데이트한다.

• 장점
  • 모니터링과 테스트를 업데이트 과정에서 진행할 수 있다.
    • 대놓고 A/B 테스트가 가능하다.
• 단점
  • 서비스 안정성에는 유리할 수 있겠지만, 사람 손을 조금 거치는 것이 전제되는 전략으로 번거로울 수 있다.

카나리 배포는 사실 뭔가 짬뽕 맛이 조금 난다.
그리고 분류를 해내기에도 기준도 매우 애매하다.
가령 그린 버전을 조금만 배포하지 말고, 블루 버전 개수랑 완전히 똑같이 해서 새로 만들면 그냥 블루그린 아니냐?
(사실 블루 그린과는 명확히 구분되는 것이, 블루 그린은 트래픽을 동시 라우팅하지 않는 방식이다)
또, 블루 버전을 조금만 내리고 그 자리에 그린 버전을 올리는 식으로 전략을 취하면 이게 롤링 버전이랑 뭐가 다르냐?

나는 이 전략의 유효점은 롤링 전략과 다르게 중간 업데이트 과정을 운영자의 조절이 가능하다는 부분에 있다고 생각한다.
핵심은 업데이트 중간에 한 단계를 더 두어서 이 단계를 각종 운영에 활용한다는 것에 있다.
아무리 개발을 잘 했어도 운영 환경에서는 문제가 발생할 수도 있다.
이럴 때 중간 과정을 두어서 문제가 생기면 빠르게 그린 버전을 다시 내리고 수정을 할 수 있다.
또한 블루 버전과 그린 버전 중 어느 걸 사용자가 더 선호하는지 확인하고 싶을 수도 있다.
이럴 때 두 버전으로 트래픽이 라우팅된다면 간편하게 a/b 테스트를 진행할 수 있다.

그래서 사실 나는 안정적인 서비스 운영의 전략의 정점으로 카나리가 있다고 보는 편이다.
그냥 애초에 개념 자체가 중간 과정을 둔다는 것이 핵심이기 때문이다.

참고

• https://www.samsungsds.com/kr/insights/1256264_4627.html